In some modern communications networks, service instantiation and management can be a labor intensive process. Services in modern networks typically are provided by vendor equipment that can be custom made to provide the desired functions. In addition to the time required to create and manufacture the desired equipment, operations required at the network to accommodate or incorporate the new equipment may result in long lead times and/or delayed service instantiation, and because of the steps required to configure and/or accommodate resources, activating a service may be a long process that cannot be shortened.
Furthermore, redirection of flows in networks generally can be performed by a control plane associated with each vendor. Generally, the control plane can be integrated with the data plane and therefore these planes may be inseparable from one another. Similarly, in modern networks, service and network configurations may be intertwined. Thus, if an operator changes a network element, the service itself may be re-defined. Still further, in modern networks access service features may be intertwined with flow service features. Thus, each flow service may need to specify particular access services.
Because of these and other factors, each function of a service on a network may be handled by different equipment, vendor control functionality, and/or network organizations. This approach, as well as the need to redefine services as equipment is added, updated, or replaced, can create difficulties. In particular, because services, resources, and flows may be intertwined with one another, changing one of the three may affect the others and create obstacles to service creation, instantiation, execution, and/or service management after activation.
Furthermore, the complexity of network changes and/or service changes can require that various development, test, deployment, and user acceptance testing (“UAT”) and operational readiness testing (“ORT”) operations may need to be iterated multiple times on a proposed service to ensure that the service is ready for deployment. This iterative process can take months. As a result, deployment of a service may be an extended process and by the time the service is activated, some equipment or functionality may be obsolete. If equipment or functionality is upgraded, the iterative process must begin anew, resulting in further delays and complexity.
Operation support systems (“OSS”) can currently be used to create services. The process is very laborious where a product manager will define a service in writing and hand off to the system engineer who will define the service in a more detailed technical specification which defines not only the service but the network configuration based on a specific vendor network element. This technical specification is then handed off to the software designer who translates this specification into a software architecture and design. Then the developer codes the software which is then tested and validated against the product manager and system engineer and software architecture and design.
All the above-described manual handoffs of documents can be slow and laborious since many reviews of all the parties may be needed to make sure concepts and details are understood and aligned. Then the various phases of testing can be done by different groups who may interpret and validate the software delivered from different perspectives—software architecture and design, system engineering and finally product management's original description. Many of today's network and services have distributed control. This can be cumbersome in updating and changing flows or services from a network wide or customer perspective vs a nodal view.